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(54) Reuse of hardware components 

(57) The invention relates to a method for designing 
an electronic system comprising at least one digital part, 
comprising the steps of : 

• representing a behavioral description of said sys- 
tem as a first set of objects with a first set of relations 
therebetween; 



refining said behavioral description into an imple- 
mentable description of said system, said imple- 
mentable description being represented as a sec- 
ond set of objects with a second set of relations ther- 
ebetween; and 

retaining at least one of said second objects in a 
library. 
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Description . ' , 

Field of th invention 

5 [0001] This invention relates to a method for reusing electronic hardware component designs as a part of other 
designs. 

State of the art 

10 [0002] A design methodology and a design environment for a hardware/software system co-design environment has 
been disclosed previously in EP-A-772140 describing a hardware/software co-design environment and design meth- 
odology based on a data-model that allows to specify, simulate, and synthesize heterogeneous hardware/software 
architectures from a heterogeneous specification. Said environment and said methodology are based on the principle 
of encapsulation of existing hardware and software compilers and allow for the interactive synthesis of hardware/ 

is software and hardware/hardware interfaces. Said database is compiled on a memory structure adapted for access by 
executable programs on a computer for generating the implementation of said heterogeneous essentially digital system, 
comprising a plurality of objects representing aspects of said digital system wherein said. objects comprise primitive 
objects representing the specification of said digital system and hierarchical objects being created by said executable 
programs while generating the implementation of said digital system, said hierarchical objects being refinements of 

20 said primitive objects and having more detail and preserving any one or all of said aspects to thereby generate said 
implementation of said digital system; and further comprising relations inbetween said primitive objects and inbetween 
said hierarchical objects and between said primitive objects and said hierarchical objects; and further comprising func- 
tions for manipulating said objects and said relations. This type of design environment and method , disclosed in EP- 
A-7721 40, uses objects that represent aspects of the digital system. This type of design environment needs functions 

2S for manipulating the objects, in order to achieve an implementation of the digital system. These functions and the 
executable programs compiled on a computer refine the primitive objects and give rise to the implementation. Th 
present patent application as well as EP-A-867820 on the other hand disclose another type of design environment and 
design methodology. EP-A-867820 is incorporated herein by reference. The present patent application discloses a 
design environment and design methodology that faces another problem, as summarised herebelow. 

30 [0003] The rush forward of digital implementation technology faces contemporary chip designers with ever increasing 
design complexities. This makes the ability to reuse components in a system an essential design skill. Examples of 
such components are embedded cores, or complex random logic blocks. The established view on reuse is focused at 
the structural level. A component is made reusable by matching it to a standard interface. This interface defines input/ 
. output signals, their timing relationship etc. Such an interface allows to hide the detailed design of a component as 

35 intellectual property (IP) of a designer, and yet makes the component available for reuse. The reuse of hardware 
components at the structural level is not without problems. Several reasons are mentioned for this: 

• Reuse is in the first place a matter of reusing functionality, not structure. It happens often that a component can 
be 'almost' reused, but requires additional encapsulation to match the right behavior. For instance, a Digital fitter 

40 can have the ideal characteristic and performance for a modem system, but contains a serial coefficient program- 

ming input instead of the required parallel one. 

• Structural reuse seals the behavior of a component in a closed box behind the reuse interface. As a result, th 
reused behavior can only be manipulated indirectly through this interface. Introducing for instance a wait state in 
the operation of a memory controller might require cumbersome interface manipulations. 

45 • Current hardware development environments are good in capturing, simulation and synthesis of hardware com- 
ponents. They do however a bad job in manipulating the same descriptions. As an example, VHDL defines a 
component as an entity with a well defined port set. It is not possible to strip the ports of an entity depending on 
some external design condition. 

so [0004] As shown in table 1 , the difficulties of reusing structure can be substantial. The table shows some statistics 
for a DECT transceiver. It lists the total number of blocks, and the amount of blocks that have a programming interface 
function (prog). The RT-VHDL line count is shown, first without this programming function (wo/prog) and next including 
it (w/prog). It clearly shows the extra RT coding required by one extra per-block function. 
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Block 


count 


RT-VHDL line count 


Total 


prog 


wo/prog 


w/prog 


I DECT 

L. 


25 


23 


17K 


28K 


Table 1 : RT counts for DECT design 





[0005] This situation has been recognized by other authors as a 'Silicon Ceiling' (G. Martin. Design methodologies 
for system \evel ip. In Proa DATE 1 998, pages 286-302), Research solutions have been either to encapsulate Vr?DL 
wrthin an advanced design environment (G. Lehmann, B. Wunder, and K. Muller-Glaser A vhdl reuse workbench In 
o J ' P8geS 412 " 417 ) or else to extend semantics of VHDL itself (P. Ashenden, P. Wiisey and D 
U9h genericit y in suave ' ln Proc - VIUF 1 997 Fall Conf pages 1 70-1 77 and a Djafri and J. Benzakki 
Oovhdl; Object oriented vhdl. In Proc. VIUF 1997 Fall Conf., pages 54-59). 

Aims ot the invention 
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[0006] A primary aim of the present invention is to provide a method for reusing complete electronic hardware com- 
ponent designs in other hardware designs. 

[0007] A further aim of the present invention is to provide a method enabling reuse the function of an electronic 
hardware component in another design. 

[0008] Another aim of the present invention is to provide a method enabling reuse of at least a part of the functionality 
ot an electronic hardware component design. 

Summary of the invention 

[0009] The present invention concerns a method for designing an electronic system comprising at least one digital 

part, comprising the steps of : 

• representing a behavioral description of said system as afiret set of objects with afirst set of relations therebetween- 

• refining said behavioral description into an implementable description of said system, said implementable descrip- 
tion being represented as a second set of objects with' a second set of relations therebetween- and 

• retailing at least one of said second objects for reuse in the design of a second electronic system. 

[0010] Preferably, said step of retaining comprises the substeps of : 

• selecting out of said second set of objects a subset of second objects having substantially the same functionality 
and/or characteristics in said implementable description; 

• creating a class representing; said same functionality and/or characteristics; and 

• storing said class in a library. 

[0011] Said class can comprise methods (functions of an object). These functions are part of the objects in contrast 

rented I hEpXSS^ d8tail ^ EP " A " 77214 °- The ,Unctions recited in EP-A-772140 are external to the objects 

[001 2] The second electronic system preferably comprises objects that are instances of said class 
[001 3] Said second set of objects preferably have a common semantics. 

[0014] Preferably, said class executes a parametric manipulation on said second set of objects. Advantageously 
said parametnc manipulatbn is a parametric expansion. 

[0015] Expansion of existing objects can include the addition to an object of methods (functions of an object) that 
create new ob,ects. Said object is said to be expanded with the new objects. The use of expandable objects allows to 
use ^rneta-code generation: creating expandable obj cts impli s an indirect creation of the new objects 

1!L . rablv ' saidclassisar usable compon nt. In a first preferred mbodiment of the pres ntinv ntion th 
method can further compris th st ps of : 

• describing the electronic system by formal means in a formal description, said formal description being the repre- 
sentation of saidbehavioral d scription of said system as said second set of objects with said second set of relations 
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therebetween; 

• selecting a functional entity within said system, said functional entity corresponding to said subset of second objects 
having substantially the same functionality and/or characteristics in said implementable description ; 

• formulating said functional entity as a reusable entity by formulating said functional entity as a parametric expansion 
of said formal description ; 

• describing said reusable entity as said reusable component using said formal description such that said reusable 
entity is a parametric expansion of said reusable component. 

[0017] Said formal description is preferably formulated in an object-oriented programming language, and said par- 
ametric expansion is preferably performed on an object hierarchy. 

[0018] In a second preferred embodiment, the method further comprising the steps of designing another electronic 
system comprising at least one digital part and wherein said class is used for creating objects within the design of the 
other electronic system. The method can further comprise the steps of : 

• selecting the behavioral register-transfer level design description of a first hardware component within the design 
of said electronic system, said hardware component having at least a part of the desired functionality of a target 
hardware component that is comprised in the design of said other electronic system ; 

• determining the changes that are necessary to reuse said hardware component in the design of said other electronic 
system ; and 

• formulating the changes that are necessary to reuse said hardware component in a class that is able to transform 
the implementable description of said hardware component into said target hardware component. 

[001 9] Said changes can comprise a parametric expansion performed on an object hierarchy. Preferably, said object 
hierarchy is expressed using an object-oriented programming language, advantageously C++. 

[0020] Said behavioral description is preferably described as a hierarchy of one or more objects selected from the 
group consisting of: 

• finite state objects, 

• state objects enumerating the states of said finite state objects, 

• transition objects that relate said state objects, 

• instruction objects that represent processing done when said transition objects are executed, and 

• operation objects that make up parts of said instruction objects. 

[0021] The changes are preferably selected from the group consisting of: 

• adding extra state objects and/or transition objects to a finite state machine, . 

• adding extra operations to an instruction objects, 

• merging two or more behavioral descriptions, 

• removing an object from said hierarchy, . * 

• modifying an object from said hierarchy, and 

• any combination of the above. 

[0022] The behavioral register-transfer level, design of the first hardware component is preferably expressed using 
an object-oriented programming language, said object-oriented programming language advantageously being C++. 
[0023] The method according to this second preffered embodiment can further comprise a refining step, said refining 
step comprising formulating structural characteristics of a hardware component as an object hierarchy of one or more 
objects selected from the group consisting of: 

• finite state objects, 

• state objects enumerating the states of said finite state objects, 
transition objects that relate said state objects, 

• instruction objects that represent processing done when said transition objects are executed, and 

• operation objects that make up parts of said instruction objects. 

[0024] Said refining step can comprise th addition of new objects, permitting interaction with existing objects, and 
adjustments to said existing objects allowing said int raction. 

[0025] Preferably, said refining step is performed in an extendible environment and comprises expansion of existing 
objects. 
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S. — jessst a method for the reuse * ■ first hardware * h — 

5 " onKSl^^f fa r e9 'f er - transfer level des *9n description of a first hardware component with at least a part 

- ?^S^^2S^«°L a tar9 ? C0mP0nen, that iS C ° m P rised in ~ id h ^re design " 

it necessary, transform said design description to an object hierarchy, 

« ESl^i^oSS , 3i to H ,h " PfeSent inVenti ° n Can bS fUrther characterised in «« ^id object hierarchy is 
being c!! 9 ^ject-onented programming language, said objectoriented programming language preferably 

[0028] The changes can be chosen from the group consisting of: 

- adding extra states or transitions to a finite state machine 

20 - adding extra operations to an instruction to provide extra functionality 
merging two or more descriptions, 

- modifying states, transitions, signals and/or instructions, and/or 
any combination of the above. 

KLglfeps " r6lateS t0 3 mSth0d f ° r thS rSUSe 01 3 P art oi a hardwa ' e characterised by7h 

30 . describing said hardware design by formal means in a formal description 

- selecting said part of said hardware design 

- formulating said part as a reusable part by formulating said part as a parametric expansion of said forma, descrip- 

" TnT ng , 3 reUSab,S protot yP e of said reus able Part using said formal description such that said reusable cart is 
a parametric expansion of said reusable prototype. reusable part is 

Engulf h3S the meanin9 * a,r 0b i ect - used in ObjectOriented program- 

° h JS f ' U r a " y C ° mpriSeS meth0dS ' WhiCh aref unctions that can ^ permed 
H,h fI=T , ,?? J 3S descr,bed In tn« patent application show all the features of objects from an OOPL 

ncwL k "" S,anCe va,la ' tes ). <™*ods> and mnernance (parems, or 

Short description of the figures: 

SSS SrJf^^!T 00 ^"^ BP,00 ^ tMn d aninterblock synchronization interfac . 
£S r o d * b a Pragramm.ng nterface for a data processing unit of an ASIC 
LU038J Rgur 3 shows a ones-counter circuit. 

rWS ? ure t ^ PiCtS thS S3me °" S COUnter in a behavioral RT description 

[0040] F,gure 5 describes th two communicating proc ssors of fig. 1 . expanded according to the present invention 
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with the synchronizer object. 

[0041] Figure 6 depicts the programming interface of figure 2 as a behavioral reuse object according to the present 
invention. 

[0042] Figure 7 shows the ones-counter behavioral RT as in figure 4, expanded according to the present invention 
5 with the prog_itf object. 

[0043] Figure 8 describes schematically the present invention. 

Detailed description of the invention 

io [0044] Being faced with structural reuse problems in several recent demonstrator designs, the inventors developed 
a hardware reuse mechanism at the more abstract behavioral RT-level. 

[0045] The invention concerns a method for behavioral reuse. The advantage over current, structural reuse, is that 
the reuse interface is defined at a much higher level. In the present invention, the reuse interface is defined at the 
behavioral RT level. The RT descriptions are entered in an object oriented environment. The following are essential 
is advantages of this reuse method: 

Dislike functions in the same component can be developed independently. 

Reusing functions instead of structure enables compact descriptions that are more easy to understand and main- 
tain. 

20 - Distribution of the reusable objects can be done as object code. Therefore, intellectual property of a reused function 
is safeguarded. 

[0046] The present invention will be further clarified using non-limiting examples and figures. 

2S Problem 1 :. Interblock synchronization according to the state of the art 

[0047] Figure 1 shows a simple case of communicating processors. Each of the processor's behavior is described 
through a finite state machine (FSM). The nodes indicate an execution state, while the transitions between states 
correspond to one clock cycle of data processing. Each of the FSM thus represents the schedule of an algorithm. The 

30 GET and PUT operations show at which clock cycles the processors communicate data. This shows that there is an 
input/output dependency between processors P1 (1) and P2 (2). When unsynchronized, processor P1 (1) produces 
output data every second clock cycle. This data is consumed by processor P2 (2) with a variable schedule of two or 
three clock cycles. The communication of data thus introduces a synchronization requirement between P1 and P2 to 
guarantee correct operation of the system. The current practice to solve this kind of communication consistency problem 

35 is to use one of the following methods. 

a) To adapt each of the processor's description such that they are always in perfect synchrony. 

b) To introduce a global synchronization mechanism that forces communication synchrony. 

c) To embed a fixed communication protocol onto the IO ports. 

40 

[0048] When thinking in terms of reuse, neither of these three solutions is optimal. This is because the communication 
scheme can change in the next application, which necessitates a change to the processor description. Cases a) and 
b) force designers to solve two interdependent tasks at the same time (local and global behavior), resulting in a difficult 
and hard-coded solution. Case c) implies the use of a universal communication mechanism which might not be needed 
45 in the next application. 

[0049] Structural reuse becomes hard, or in the best case causes an overhead in silicon and/or timing. 

Problem 2 : a programming interface according to the state of the art : 

50 [0050] The second example, a programming interface, is a common feature in ASICs. An example is shown in figure 
2. It consists of two blocks out of a synchronous ASIC design. Only the parts relevant to the programming interface 
are shown. The first is a Master Interface (11 ). The purpose of this block is to make the data processing registers of 
the ASIC programmable from the outsjde world. The second block, Data Processing (13), is a functional component 
of the ASIC. This block has a local controller FSM 15, that sequ nc s instructions to a datapath. Doing this, a digital 

ss signal processing (DSP) algorithm such as equalization can b impl mented. Furth rmore, this local controller also 
performs additional instructions, which are invoked by the master interface through pgm and copy. 
[0051] The data proc ssing block 1 3 has two modes of operation: an active mode, and a programming mode. The 
desired mode is set by the master int rface through the value of pgm. The data processing block also signal which 
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mode is currently active through a status bit. The data register D (17) is updated when the mast r interface sets the 
copy bit and at the same time the data processing block is in programming mode. 

[0052] A simple protocol controls the programming of the data register D. When a value is available in register I (1 2) 
the master .nterface sends a program mode request to the data processing block by setting the pgm bit Depending 
on the real time requ.rements inside the data processing algorithm, the data processing block will enter the program 
mode some cycles later and signals this to the master interface through the status bit. The master interface then can 
update the data register D by setting the copy bit. 

[0OS3J The design complexity of the data processing block lies in the simultaneous presence of DSP algorithm and 
programming protocol. As a consequence, the designer of the data processing block needs to master both a DSP 
algorithm schedule and a protocol. Whether the FSM is described hierarchically or not does not matter: the designer 
needs to think of two things at once. 

[0054] In addition, using current HDL environments, it is not possible to design the DSP processing schedule of the 
block independently of the protocol, which degrades potential reuse possibilities. 

The object oriented RT data model : the ones-counter. 

[0055] Herebelow, the object oriented RTdata model is explained in a bottom-upfashion, startingf ram an architecture 
and working upwards to an object oriented specification. This will clearly show the relation between the objects and 
he implementation. An example target architecture is shown in figure 3. For the sake of clarity, a simple processor 
that counts the number of "1 ' bits in a bit stream, is used. It contains the following elements : 

" foof f Path WitH re 9 istera - Register N (21) holds the number of bits seen after the last reset, while register C 
(23) holds the value of the currently observed bit in the bit stream. It is assumed that the count register N (21 ) has 
sufficient width to hold the maximum bit count during two subsequent reset instructions. 

- A controller FSM (25) that can increment, hold or reset the count register N (21) in the datapath. 

[0056] Figure 4 shows a behavioral RT specification of the same ones-counter. The specification consists of a Mealy- 
type state transition d.agram, and three RT instructions rst, inc and hold. These correspond to the datapath actions in 
case of reset, observation of '0' and observation of 'V respectively. The behavioral specification contains all the elements 
that make up the object oriented model. The C++ specification of the same behavior shown below corresponds closely 
to the representation of figure 4. Some comments is included to identify the different elements of the specification 
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- 

1: elk ck; 7/clk is a class, ck an object of 

2 : //said class 

3: sig C(ck,0); //sig is a class, 

4: sig N(ck, 0); //C and N are objects of class sig 

5: sig input; 
6: sig output; 

7: bus IB; //bus is a class, IB and OB are objects 

8: bus OB; 
9: 

10: sfg rst; 
11: N = 0; 
12: C = input; 
13: rst << in (input, IB) ; 

14 : //=/ «/ + are operation objects 

15: sfg inc; 
16: N = N + 1; 
17 : C = input; 
18: output = N; 
35 19: inc « in (input, IB) « out (output , OB) ; 

20 : , //in is a constructor, it is a class which 

//creates intermediate/temporary objects 

21 : sfg hold; 
22 : C = input; 

23: hold << in (ihput/lB) << out* ( output , OB ) ; 
24: 

25: fsm ones_cnt; //fsm is a class 
26: state sO; //state is a class 

27 : state si; 

28: ones_cnt « deflt(sO); .//deflt is a constructor 
29: ones_cnt « si; 

ss 
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30: 


sO 


« 


31: 


si 


« 


32: 


si 


« 



////end is a constructor 



[0057] The data processing is expressed in terms of sig classes, that represent plain signals or registers (lines 3-6) 
Datepath instructions such i as rst, inc. and hold are described using the sfg classes. Each of these group a number of 
signal expressions (lines 1 0-23). The I/O ports of the behavior are indicated using bus classes. The control description 
of the ones-counter is captured by a direct modeling of the FSM description in figure 4. Each state of the ones^ounter 
IZ7* S T Tp 5 ™ f! asS ( ,ines 26 - 27 >- The fem clas * groups a number of state classes, identifying one as the 
a aII r 2S ' 29 : The data P ath Actions are assigned to control steps by creating FSM transitions (lines 
30-32). A ransition contains a source state, a transition condition, a datapath instruction to execute, and a target state 
The comp ete RT behave of the ones-counter thus is captured as an object hierarchy. The objects are typical behav- 
.oral-RT e ements such as signals, instructions, and control states. C++ operator overloading is used extensively to 
construct the object h.erarchy. After this C++ description has executed, a reference to the fsm object is sufficient to 
retrieve the entire processor description as a set of interrelated objects. The reference can be used to simulate the 
descr.pt.on and generate synthesizable HDL code for it. Both operations are similar to each other and are a specific 
way of interpreting the object hierarchy stored in memory. 

Meta-code generation 

2S [0058] The design environmetn OCAPI. as disclosed in EP-A-867820, is incorporated herein by reference The de- 
™«rr me AP ' iS WS " SUked f ° r applyins the method according to the present invention 
[0059r OCAPI internally can use meta^ode generation. With this, it is meant that there are code generators that 
generate new fsm , sfg- and "sig" objects (instances of fsm, sig and sfg classes) which in turn can be translated to 

syntnesi2aole code. 

30 [0060] The use of expandable objects allows to use meta^ode generation: creating expandable objects implies an 
indirect creation of the new objects. 

[0061] Meta-code generation is a powerful method to increase the abstraction level by which a specification can be 
£t ™ ^T' V*S*° POSSib ' e t0 make P arame,ri2ed descriptions, possibly using conditions. Therefore, it is the 
key me hod of soft-chip components, which are software programs that translate themselves to a wide range of im- 
plementations, depending on the user requirements. 

[0062] The meta-code generation mechanism is also available to one as a user. To demonstrate this, a class will be 
presented that generates an ASIP datapath decoder. 



An ASIP datapath idiom 



[0063] An ASIP datapath, when described as a timed description within OCAPI. will consist of a number of signal 
lowgraphs and a finrte state machine (fsm). The signal flowgraphs express the different functions to be executed by 
he datapath. The fsm description is a degenerated one. that will use one transition per decoded instruction The 
45 ^ 1 ran o C0nd,tl0n I s ^pressed by the "instruction- input, and selects the appropriate signal flowgraph for execution. 
« [0064] Because the finite state machine has a fixed, but parametrizable structure, it is subject for meta^ode gener- 
ation. One can construct a "decoder- object, that generates the fsm- for you. This will allow compact specification of 
the instruction set. First, the "decoder" object (which is present in OCAPI) itself is presented 
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the include file 

5 

#define MAXINS 100 
10 #include "qlib.h" 

class decoder : public base 

15 { 

public: 

decoder (char *_name, elk &ck, dfbfix &__insq) ; 
20 void dec(int _numinstr) ; 

ctlfsm &fsm(); 

void dec(int _code, sfg &) ; 
25 void dec(int _code, sfg &, sfg &) ; 

void dec (int _code, sfg &, sfg sfg &) ; 
private: 

char *name; 

35 
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elk *ck; 
dfbfix *insq; 

int inswidth; 
int numinstr; 
int codes [MAXINS] 

ctlf sm _f sm; 
state active; 

sfg decode; 
_sigarray *ir; 

end * deccnd(int ) 
void decchk(int ) 

}; 

— the .cxx file 

#include "decoder. h" 

static int numbits (int w) 
{ 

40 int bits — 0; 

- * while (w) 

{ 

45 bits++; 

W = W >> 1; 
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return bits; 



} 



int bitsetfint bitnum, int 
{ 
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return (n & (1 « bitnurii) ) ; 

} 

decoder :: decoder (char *_name, elk &_ck, dfbfix & insq) 

: base (__name) 

{ 

name = _name ; 

insq = _insq. asSource (this) ; 
ck = &_ck; 
numinstr =0; 
inswidth =0; 

_fsm « _name; 

// active « strapp (name, "_go_" ) ; 

active « "go"; 

_fsm « def It (active) ; 

} 

void decoder :: dec (int n) 
{ 

// define a decoder that decodes n instructions 
// instruction numbers are 0 to n-1 
// create also the instruction register 
if (!(n>0)) 
' { 

cerr « ERROR: decoder " « name « " must 

have at least one instruction\n" ; 

exit(0); 

} 

inswidth = numbits (n-1) ; 

if (n > MAXINS) 

{ 

cerr « ERROR: decoder " << name « " 

exceeds decoding capacity\n" ; 

exit(0); 
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} 

dfix bit(0,l,0,dfix::ns); 

ir = new _sigarray ( (char *) strapp (name, «_i r » ) 
inswidth, ck, bit); 
decode.startsf); 
int i; 

SIGW(irw, dfix(0, inswidth, 0, dfix:;ns)); 
for (i=0; i<inswidth; i++) 
{ 

if (i) 

20 -(*ir) [i] = cast(bit / irw » 

_sig(dfix (i, inswidth, 0,dfix: :ns) ) ) ; 
else 
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(*ir) [i] = cast (bit, irw) ; 



decode « strapp ( "decod" , name) ; 
decode « ip(irw, *insq) ; 



void decoder: :decchk( int n) 
{ 

// check if the decoder can decode this instruction 
int i; 

if (! inswidth) 
{ 

cerr « ERROR: decoder V « name « " must 

first define an instruction width\n"; . 
exit (0) ; 

50 } 

if <n > ({1 « inswidth) -1) ) 
{ 



ss cerr « ERROR: decoder " « 



name « 
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cannot decode code " « n « "\n"; 
exit (0) ; 

} 

for (i^O; i<numinstr; i++) 
{ 

if (n == codes [i] ) 
{ 

cerr << "*** ERROR: decoder " « name « 
decodes code n « n << " twiceW; 
exit (0) ; 

} 

20 } 

codes [numinstr] = n; 
numinstr++; 
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} 



end ^decoder : rdecend (int n) 
{ 

// create the transition condition that corresponds 
// to the instruction number n 
irit i; 

end *cresult = 0; 
if (bitset (0, n) ) 

cresuit = &_cnd( (*ir) [0] ) ; 
else 

cresuit = & ( !_cnd( (*'ir) [0] ) ) ; 

for (i = 1; i < inswidth; i++) 
{ 

if (bitset (i, n) ) 

cresuit = &{*cresult && _cnd ( { *ir ) [i] ) ) ; 

else 

cresuit = &(*cresult && !_cnd ( ( *ir) [i] ) ) ; 

} 
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return cresult; 

} 

void decoder: : dec (int n, sfg &s) 
{ 

// enter an instruction that executes one sfg 
decchk (n); 

active « *deccnd(n) « decode « s « active; 

} 

void decoder: : dec (int n, sfg &sl, sfg &s2) 
{ 

// enter an instruction that executes two sfgs 
decchk (n) ; 

active « *deccnd(n) « decode « si « S 2 « 
active; 

} 

void decoder:: dec (int n, sfg &sl, sfg &s2/ sfg & s3 ) 
{ 

// enter an instruction that executes three sfgs 
decchk (n) ; 

active «, *deccnd(n) « decode « si « s2 « s3 « 
active; 

} 

ctlfsm & decoder: :fsm() 



{ 

so return _fsm; 

} 



55 n Sr i™H^ ^ ,nC,P S 9 " rati ° n ar thS ,0 "° Win 9- Each instru <*°" <™ the ASIP decoder is defined as a 
num^naddrt ontoon to thre signal flowgraphs thai n dtob xecuted wh n this instruction is decoded The 
the inttmof' ° f * instruction numbere used and warns one if one introduces a duplicate If 

IJSiSCZX" un,que ' jt is sp,it up into a number of instruc,ion brts - and a ,sm ,ransi,ion condHion is 
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The ASIP datapath at work 

[0066] The use of this object is quite simple. In a timed description were one wants to use the decoder instead of a 
plain f sm" , one inherits from this decoder object rather then from the "base" class. Next, instead of the fsm description, 
one gives the instruction list and the required signal flowgraphs to execute. 

[0067] As an example, an add/subtract ASIP datapath is defined. One selects addition with instruction number 0, 
and subtraction with instruction number 1 . The following code (that also uses the supermacros) shows the specification. 
The inheritance to "decoder 11 also establishes the connection to the instruction queue. 

— include file 
#ifndef ASIP_DP_H 
ttdefine ASIP DP H 



class asip_dp : public decoder 

20 { 

public: 

asip_dp (char *name, 
25 elk &ck, 

FB Scins, 
_PRT(inl), 
PRT(in2), 
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_PRT(ol) ) ; 

private; 

PRT(inl) ; 
PRT(in2); 
PRT(ol ); 

}; 

— code file 

#include * *asip_dp.h' r 

dfix typ(0, 8, 0) ; 
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asip_dp: :asip_dp 
elk &ck, 
FB &ins, 
_PRT(inl) , 
_PRT(in2) , 
PRT(olJ) 



(char *name, 



{ 



IS_IP(inl) ; 
IS_IP(in2) ; 
IS OP(ol) ; 



: decoder (name, ck, ins), 
IS^SIGCinl, typ), 
IS_SIG(in2, typ), 
IS_SIG(ol, typ) 
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SO 



SFG(add) 
GET (inl) 
GET (in2 ) 
ol = inl + in2; 
PUT(ol) ; 



SFG (sub) ; 
GET (inl) ; 
GET (in2) ; 



17 



( 



( 



EP 0 991 000 A2 



ol = inl - in2; 
PUT(ol) ; 



10 



dec(2); // decode two instructions 
dec(0, SFGID(add)); 
dec (1, SFGID(sub) ) ; 
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[0068] To conclude, one can see that meta-code generation allows reuse of design 'idioms" rather then design "in- 
stances". Intellectual-property code generators are a direct consequence of this, 

[0069] Having a design description stored as an object hierarchy in memory creates the possibility of manipulating 
it. These manipulations can for instance create new state objects, define extra instructions with signal objects, etc. 
Some examples where this can be useful are: 

Attaching extra wait states or transitions to an fsm in order to add a synchronization capability 

Adding extra operations to an instruction to produce enhanced capabilities, such as for instance overflow detection 

in the ones-counter example. 

Merging of different functional descriptions m\o one description that can then be jointly optimized in a synthesis tool. 
Creation of new reuse classes, that are constructed using existing ones. This corresponds to the well known 
abstraction mechanism of C++, and is the key to the reuse method of the invention. 

[0070] Figure 8 shows a summary of the present invention : a hardware design 53 is made using class library 51 , 
resulting in objects 55 that describe an implementable description of the design. The objects 55 are grouped in new 
classes 57, which can be integrated is the class library to form an extended class library 59. The new classes can then 
be used for the design of new hardware. The second design 61 can be made using objects' 63, resulting in an imple- 
mentable description' and second hardware'. 

[0071] Behavioral reuse is applied by a two-step process. First, the reuse problem is formulated as a (possibly par- 
ametric) expansion of RT-behavior. This is done in terms of manipulations on the OO-RT model (adding/ modifying of 
states, transitions, signals, or instructions). As a second step, the manipulation's captured in an class that can be 
reused. Such a class contains an expand() method (a parametric expansion of the object), which manipulates existing 
OO-RT behavior. The arguments of expand() are called the hooks of the behavioral reuse object. The hooks indicate 
the starting point for the manipulations on the OO-RT model. A small example makes the concept of expand() method 
and hook clear. Consider adding a new state to an fsm. This can be described in a behavioral reuse class as: 
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so 



55 



class addstate { 
public: 

addstate () ; 
expand (fsm &f) { 

state *s0 = new state; 
f << *so; 

} 



[0072] The reus class addstate has one hook: a reference to the fsm which receiv s the n w state. Th expandQ 



18 



( 



EP 0 991 000 A2 



10 



75 



20 



2S 



30 



35 



40 



45 



SO 



method of addstate appends this state to th fsm. 



Example 1 



, Interblock synchronization as an application of beh^ i rt reuse a^.ng to the invent™ 



55 



Th. protocol imolomentafcn S sVt , P U5< " 1 85 a trans « i<> " c°nd«ton in the expanded FSM 



0: 

1: 

2: 

3: 

4: 

5: 

6: 

7: 

8: 

9: 

10: 

11: 

12: 

13: 

14: 

15: : 

16: 

17: 

18: 

19: 



*~*definitions : 

- for any transrtion in a finite state machine 
running from state 'A' to state 'B', 

call 'A' a source state of this transition 
call 'B' a target state of this transition 

- for any transition in a finite state machine 
with source state 'A' and target state 'B\ 
call 'pred(transition)' any transition for 
which 'A' is a target state 

*** algorithm 

for each synchronized I/O access transition { 
add new wait transrtion on the source state - 
update transition conditions from the source state 
} 

for each synchronized I/O access transrtion { 
insert instruction reql on all pred(transrtion) 
insert instruction reqO on all Ipred(transition) 

for each transition 
insert instruction read 



Tsa! S : aSJed HoT ^TT ** tW ° "° aCC6SSeS SUbieCt to ionization 

problemThe Z^ZSr obLe S h " T formu,atin 9 ,he synchronization problem as a behavioral reuse 

^^^S^S ^ read " y rSP,aCed bV 3 ^ m ° re heated one wrthout additional modm- 
Example 2 : The programming interface as a behaving. , a „ ^ obiect a ^ nrrtinr , t „ the present inVflntjnn 

ing (33) itself butdoes notn , ^ r ,s responsibl for the description of th data process- 

though an class oroo m<J£ 7 Pr ° tOCO> " Hh the maS,er interfac • Rath this P««ol is avaHable 

ugh an class prog_rtf (35). To .mp.ement th programming interface in the data proc ssing block, a numb r of 
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hooks must be given to the programming interface. These include: a reference to the data register for implementing a 
write operation from the master interface and a refer nee to a state at which the block can go into programming mode. 
Given these hooks, the expand method of prog_itf can be called to implement the programming interface into the block. 
An example of the op ration of progjtf is shown in figure 7. Data register D (41 ), as well as state S2 (43) of the original 

s FSM where hooked (45) onto the programming interface object (35). Calling the expand() method (47) of prog_itf 
modifies the original state transition diagram resulting in one as shown on the bottom of the figure. One new state is 
inserted, as well as four new transitions. In addition, four new instructions are inserted, needed for writing into the D 
register (upd), signaling the block status (statusO, statusl), and reading the master interface commands read. This last 
instruction also requires the creation of two new condition registers (prog and copy) to hold these commands. It is seen 

10 that the programming interface is an ideal candidate for reuse, since it is independent of the behavior in which it is 
embedded. It also allows very compact descriptions. In a 80 Kgate cable modem : a similar class can be used for the 
construction of an I2C programming interface. The interface class was applied to 6 different data processors in the 
modem. The complete description of the modem in C++ at the OO-RT level took 4426 lines of code, while the RT- 
VHDL, generated out of this code, took 21 798 lines. The gain in code size was for a large part credited to the behavioral 

is reuse mechanism of the programming interface. 

Example 3: comparison of two 80-kilogate designs designed with and without reuse according to the present invention. 

[0076] The method according to the present invention was applied on two 80-kilogate designs: an upstream Cable 
20 Modem and a DECT base station transceiver. For both designs, the first line indicates the C++ line count in the OO- 
RT model. The RT-VHDL line count of generated code is shown on the second line. The type of code is divided into 
reuse (reusable classes such as programming interfaces obtained according to the present invention), body (line count 
of individual block bodies), headers (.h files for C++ and entity declarations for VHDL) and system (the system level 
net list and testbench drivers). 

25 

Table 2: 
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Line count 


Reuse 


Body 


Headers 


System 


Total 


Cable OO RT-C++ 


1746 


5369 


1975 


4023 


13113 


Cable RT-VHDL 




21798 


5654 


2180 


29631 


DECT OO RT-C++ 


800 


8776 


2286 


1192 


13054 


DECT RT-VHDL 




19781 


6271 


2311 


28363 


RT line counts for 2 example designs 



J [0077] The savings in coding are obvious considering the total line count. In VHDL, the reused classes get instantiated 
in the body of blocks, which are increased considerably. . 

40 

Claims 

1, A method for designing an electronic system comprising at least one digital part, comprising the steps of : 

45 

• representing a behavioral description of said system as a first set of objects with a first set of relations there- 
between; 

• refining said behavioral description into an implementable description of said system, said implementabie 
description being represented as a second set of objects with a second set of relations therebetween; and 

so * retaining at least one of said second objects for reuse in the design of a second electronic system. 

. 2. The method as recited in claim 1 wherein said step of retaining comprises the substeps of : 

• selecting out of said second set of obj cts a subset of second objects having substantially the same function- 
55 alrty and/or characteristics in said implem ntable description; 

• creating a class representing said same functionality and/or characteristics; and 

• storing said class in a library. 
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3. The method as recited in claim 2 wherein said second electronic system comprises objects that are instances of 
said class. 

4. The method as recited in claim 2 wherein said second set of objects have a common semantics. 

5. The method as recited in claim 2 wherein said class comprises a function. 

6. The method as recited in claim 2 wherein said class executes a parametric manipulation on said second set of 
objects. 

7. The method as recited in claim 6 wherein said parametric manipulation is a parametric expansion. 

8. The method as in claim 7 wherein said expansion includes the addition of functions to an object for creatinq a new 

object. 

9. The method as recited in claim 2 wherein said class is a reusable component. 

10. The method as recited in claim 9 further comprising the steps of : 

• describing the electronic system by formal means in a formal description, said formal description being the 
representation of said behavioral description of said system as said second set of objects with said second 
set of relations therebetween; 

• selecting a functional entity within said system, said functional entity corresponding to said subset of second 
objects having substantially the same functionality and/or characteristics iri said implementable description ■ 

- formulating said functional entity as a reusable entity by formulating said functional entity as a parametric 
expansion of said formal description ; 

• describing said reusable entity as said reusable component using said formal description such that said re- 
usable entity is a parametric expansion of said reusable component. 

1 1. The method according to claim 1 0, wherein said forma! description is formulated in an object-oriented programming 
language, and said parametric expansion is performed on an object hierarchy. 

12. The method as recited in claim 2 further comprising the steps of designing another electronic system comprising 
at least one digital part and wherein said class is used for creating objects within the design of the other electronic 
system. 

3. The method according to claim 1 2 further comprising the steps of : 

«. selecting the behavioral register-transfer level design description of a first hardware component within the > 
design of said electronic system, said hardware component having at least a part of the desired functionality 
of a target hardware component that is comprised in the design of said other electronic system ; 

• determining the changes that are necessary to reuse said hardware component in the design of said other 
electronic system ; and 

* formulating the changes that are necessary to reuse said hardware component in a class that is able to trans- 
form the implementable description of said hardware component into said target hardware component. 

4. The method as recited in claim 1 3, wherein said changes comprise a parametric expansion performed on an object 
hierarchy. J 

5. The method as recited in claim 14, wherein said object hierarchy is expressed using an objectoriented program- 
ming language. 3 

6. The method as recited in claim 15, wherein the object-oriented programming language is C++. 

7. Th method as recited in claim 13, wherein said behavioral d scription is describ d as a hierarchy of on or more 
objects s lected from the group consisting of: 

• finite state objects, 
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• state objects enumerating the states of said finite state objects, 

• transition objects that relate said state objects, 

• instruction objects that represent processing done when said transition objects are executed, and 

• operation objects that make up parts of said instruction objects. 

18. The method as recited in claim 17 s wherein the changes are selected from the group consisting of: 

• adding extra state objects and/or transition objects to a finite state machine, 

• adding extra operations to an instruction objects, 

• merging two or more behavioral descriptions, 

• removing an object from said hierarchy, 

• modifying an object from said hierarchy, and 

• any combination of the above. 

19. The method as recited in claim 1 3, wherein the behavioral register-transfer level design of the first hardware com- 
ponent is expressed using an object-oriented programming language. 

20. The method according to claim 1 9, wherein said object-oriented programming language is C++. 

21. The method as recited in claim 13, further comprising a refining step, said refining step comprising formulating 
structural characteristics of a hardware component as an object hierarchy of one or more objects selected from 
the group consisting of: 

• finite state objects, 

• state objects enumerating the states of said finite state objects, 

• transition objects that relate said state objects, 

• instruction objects that represent processing done when said transition objects are executed, and 

• operation objects that make up parts of said instruction objects. 

22. Method as recited in claim 21, wherein said refining step comprises the addition of new objects, permitting inter- 
action with existing objects, and adjustments to said existing objects allowing said interaction. 

23. Method as recited in claim 21 , wherein said refining step is performed in an extendible environment and comprises 
expansion of existing objects. 

24. A method. for the reuse of a first hardware component in a hardware design, comprising the following steps: 

selecting the behavioral register-transfer level design description of a first hardware component with at least 
a part of the desired functionality of a target hardware component that is comprised in said hardware design, 
if necessary, transform said design description to an object hierarchy, 

determine the changes that are necessary to reuse said hardware component in said hardware design, and 
create an object that comprises an expandQ method capable of transforming said object hierarchy into a 
second object hierarchy that describes said target hardware component. 

25. The method according to in claim 24, wherein said object hierarchy is expressed using an object-oriented pro- 
gramming language. 

26. The method according to in claim 25, wherein the object-oriented programming language is C++. 

27. The method according to claim 24, wherein the changes are selected from the group consisting of: 

adding extra states or transitions to a finite state machine, 

adding extra operations to an instruction to provide extra functionality, 

merging two or mor d scriptions, 

modifying states, transitions, signals and/or instructions, and 
any combination of th above. 

28. The method according to claim 24, wherein the b havioral r gist r-transfer level design of the first hardware com- 
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ponent is expressed using an object-oriented programming language. 
29. The method according to claim 28, wherein said object^riented programming language is C++. 
5 30. A method as recited in claim 29 wherein the reuse of a part of a hardware design comprises the steps of: 

- describing said hardware design by formal means in a formal description, 
selecting said part of said hardware design, 

' forniulate said P art as a reusable part by formulating said part as a parametric expansion of said formal de- 
1U scnption. 

- describing a reusable prototype of said reusable part using said formal description such that said reusable 
part is a parametric expansion of said reusable prototype. 

31. The method according to claim 30, wherein said formal description is an object^riented programming language 
75 and said parametric expansion is performed on an object hierarchy. 
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Figure 4 



27 




28 



( ( 

EP 0 991 000 A2 



31 



33 



Data Processing 



Data Processing 



35 




pr-ocr_itf 
object 



Figure 6 



29 



( 



( 



BP 0 991 000 A2 




47 



prog && ! copy / prog r && copy / 
read, statusl read . statusl, upd 



Figure 7 



30 



c 



( 



EP 0 991 000 A2 




t 



CO 




CD 




CO 




co 




03 








O 






^ 















CO M 

CO fO 

(tf M 

r— < X) 









C 


JQ 


0 




-H 




4J 


c 


a 






£ 






CJ 




CO 


a 


0) 


e 









t 














c 




o 


-t-J 




. c 




<u 


a* 


E 


•H 


o 




.—t 


U 


a 


CO 


e 




M 





3C 



u 
(0 



CO 
U 



31 



r 



( 



